Networks have transformed the way people do computing. Someone with access to a personal computer or workstation can connect to the Internet and communicate with systems and people all over the world. The World Wide Web (WWW or Web) is a way of using the Internet that provides the user with access via linked documents to a wealth of information distributed throughout the globe. The WWW also allows users to execute programs running on remote servers. This capability enables users to obtain the results from programs which the user cannot run locally due to hardware and/or software limitations. It is also possible to download and run programs stored remotely on the World Wide Web. This has the potential to greatly increase the amount of software which is available to a computer connected to the World Wide Web. Network
Network protocols provide standard methods for machines to communicate with one another. The protocols indicate how data should be formatted for receipt and transmission across networks. Heterogeneous machines can communicate seamlessly over a network via standard protocols. Examples of standard Internet protocols include: HTTP, see, e.g., “Hypertext Transfer Protocol—HTTP/1.0”, http://www.ics.uci edu/pub/ietf/http/draft-ietf-http-v10-spec-03.html, by T. Berners-Lee, R. Fielding, and H. Frystyk, Sep. 4, 1995; SMTP, see, e.g, “Simple Mail Transfer Protocol”. RFC 821, J. B. Postel, Information Sciences Institute, USC, August 1982, http://ds.internic.net/std/std10.txt.; NNTP, see, e.g., “Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News”, RFC 977, B. Kantor and P. Lapsley, UC San Diego and UC Berkeley, February 1986, http://ds.internic.net/rfc/rfc977.txt.; FTP, see e.g., J. Postel and J. K. Reynolds. “File Transfer Protocol (FTP)”, RFC 959, Information Sciences Institute, USC, October 1985, http://ds.internic.net/std/std9.txt.; Gopher, see, e.g., F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, and B. Alberti. “The Internet Gopher Protocol: A distributed document search and retrieval protocol”, RFC 1436, University of Minnesota, March 1993, http://ds.internic.net/rfc/rfcl436.txt.; and WAIS, see, e.g.,
F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui, and M. Grinbaum. “WAIS Interface Protocol Prototype Functional Specification” (v 1.5), Thinking Machines Corporation, April 1990.
The client-server model constitutes one of the dominant paradigms in network programming, see, e.g., W. R. Stevens, “Unix Network Programming”, Prentice Hall PTR, Englewood Cliffs, N.J., 1990; and D. E. Corner, “Internetworking with TCP/IP” vol 1., Prentice Hall, Englewood Cliffs, N.J., 1991 which is hereby incorporated by reference in its entirety. A server program offers a service which can be accessed by multiple users over the network. A program becomes a client when it sends a message to a server and waits for a response from the server. The client process, which is typically optimized for user interaction, uses the requested service without having to know any of the detailed workings of the requested service or server. On the World Wide Web, “browsers” constitute client programs while the programs sending back information to the browser constitute server programs.
Data transfer between client and server can be achieved by many different TCP protocols such as File Transfer Protocol. In the recent years HTTP has become the defacto access protocol between web servers and client browsers. Due to HTTPs ubiquitous presence on the Internet most network administrators provide access methods for HTTP clients to gain access to Internet servers with HTTP services within their private net and gain access by users client browsers. HTTP is a stateless protocol; every request from the client to the server is treated independently. The server has no record of previous connections. The advantages of using stateless protocol are efficiency and simplicity.
Clients can send and receive data from an Internet based system, but in order to protect private or enterprise data, in many instances access to a server services are hidden behind a private net firewall or other protection mechanism and can only be accessed within the same network subnet. In such cases the server is not visible by common Internet clients. Additionally, services provided by ad hoc network servers, which can be based on mobile or temporary Internet services, require complex system administration and can create a challenge for the average individual. Other system and network issues include such matters as scalability, resource management, security, and access control, each requiring technical depth, lengthy lead time to assemble, and ongoing maintenance that can become costly. In most cases the user has to invest a great deal of time and expense. The services are limited and devices which provide services are not user friendly. The system setup and service access can present problems.
In virtually all client/server systems today, there exist two main entities which each play a crucial role in the transmission of data. A client, sender, or data source must package data in a format which can be transported over the network using one of a variety of networking protocols. A receiver or service broker must then be able to unpack the data and make use of it in its original form. It is this latter side of the data transmission relationship that we are interested in.
In order for applications running on the receivers today to obtain the transmitted data from the senders, those receivers must implement a server. A server is often a program, either in hardware or software on the receiver, which listens for incoming data. When data arrives on the receiver, it is already tagged to be delivered to a particular port on the receiver. If no listener, i.e., a server, is registered with the port on the low level network driver on the receiver, the data cannot make it to the appropriate application that the data is intended for because no server is there to hand the data to the applications for high-level processing. The server is often responsible for unpacking the data and stripping off the envelopes which encapsulate the protocol information inside of which the client packaged the data. Such an unpackaging entity on the server is called the protocol stack. At each rung up the protocol stack, the server is responsible for keeping track of the information relevant to the protocols implemented at that layer as well as performing all necessary processing to carry out the functionality at that layer.
As the size of a server increases, i.e., as the number of possible incoming connections increases, the complexity, cost, and processing overhead of that server likewise increases. For example, the code necessary to authenticate incoming connection requests and the connection setup can increase processing overhead because a separate connection handler thread or process may need be started to handle data for the new connection. Further, additional memory must be allocated per connection to be used to queue packets for each incoming connection when the server is not processing the data fast enough for that connection. As the number of simultaneous connections increases, so does the code size and memory requirements for the server program itself running on the receiver. All of these added complexities increase the cost of the receivers, more physical memory is needed to store programs and connection data and more powerful processors are needed to run these complex server programs. With the advent of less expensive and smaller networked appliances, such as light switches and smoke sensors, there grows a need to reduce the cost of the servers that would be necessary in these devices to receive commands. Likewise, due to the increased network resources needed to continuously keep these devices on-line, a solution for delivering commands to these devices that does not require these devices to continuously be on-line becomes crucial. Finally, as the need for security on sensitive appliances such as cameras and motion sensors becomes ever greater, so does the danger of using embedded servers which have a notorious history of being prone to attack by malicious individuals. Thus, a scheme is needed to deliver data to receivers that is extremely light-weight, in terms of processing and hardware requirements, does not require an always-on connection, and protects against the faults found in traditional embedded server systems today.